AWS Transfer for SFTPの構成例まとめ (2020年4月版)

AWS Transfer for SFTPの構成例まとめ (2020年4月版)

Clock Icon2020.04.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

しばたです。

マネージドのSFTPサービスであるAWS Transfer for SFTPですが、サービスが提供されてから本日に至るまでに幾つかの機能追加がされており、実装可能な構成も変わっています。
本記事では本日(2020年4月18日)時点でどの様な構成を実装可能なのか解説します。

FTPおよびFTPSサポートについて【2020.04.24追記】

2020年4月24日より、SFTP以外にFTPおよびFTPSプロトコルがサポートされる様になりました。

https://dev.classmethod.jp/articles/aws-transfer-for-ftp-and-ftps-in-addition-to-existing-sftp/

詳細は上記の記事をご覧いただきたいのですが、プロトコル毎で利用可能な構成が異なりますのでご注意ください。
加えてFTP、FTPSの全機能が使えるわけではなく機能制限もありますのでこちらもご注意ください。

【追記ここまで】

これまでの更新

実現可能な構成に触れるまえに軽く歴史的経緯について触れておきます。

サービスリリース時

AWS Transfer for SFTPは2018年11月にre:Invent 2018で新サービスとして発表されはじまりました。

https://dev.classmethod.jp/articles/reinvent2018-release-aws-transfer-for-sftp/

リリース当初の時点ではリージョン単位のエンドポイントに対して接続可能で、セキュリテグループによって接続元IPアドレスを制限するといったことは出来ませんでした。

VPC Endpoint (PrivateLink) のサポート

その後2019年3月にサービスのVPC Endpoint (PrivateLink)がサポートされ、同時にVPC Endpoint経由の接続もサポートされることになりました。

https://dev.classmethod.jp/articles/transfer_for_sftp_support_privatelink/

これまでの接続方式はPublic Endpointと呼ばれVPC Endpoint経由の接続と区別されています。
この時点ではVPC EndpointのセキュリテグループやNACLを使い接続元を制限するといった構成が可能でした。

https://dev.classmethod.jp/articles/transfer-for-sftp-restrict-ip/

VPC構成のサポート

そして2020年1月にVPCのセキュリテグループとElastic IP(EIP)のサポートが追加されました。
これが現在可能な構成となっています。

https://dev.classmethod.jp/articles/aws-transfer-for-sftp-supports-vpc-security-groups-and-eip/

現在は最初からあるPublic Endpointと、インターネット向けにEIPとTransfer for SFTPのエンドポイントを紐づけるVPC (Internet Facing)と、Private IPを使うVPC (Internal)という3つの構成を選択することが可能となっています。

VPC (Internet Facing)およびVPC (Internal)のどちらの構成も内部的には自動生成されるVPC Endpointを使う形となっており、これまでのVPC Endpoint構成を置き換えるものとなっております。
このため従来のVPC Endpoint構成はマネジメントコンソールからは初期構築できない様になっています。
(変更時のGUIのみ存在。AWS CLIからなら初期構築可能。)

注意: VPC_ENDPOINT の代わりに、内部アクセスを持つ VPC エンドポイント、またはインターネット向けアクセスを持つ VPC エンドポイントを使用することをお勧めします。
VPC エンドポイントタイプは、最大 3 つの Elastic IP アドレスをエンドポイントに直接関連付けるオプションをサポートしています。さらに、VPC エンドポイントタイプでは、VPC のセキュリティグループを使用して、クライアントのパブリック IP アドレスによるアクセスをフィルタリングできます。これらの機能は VPC_ENDPOINT ではサポートされていません。

AWS Transfer for SFTPの構成例

ここまでを踏まえて、現在構築可能な構成は以下となります。

  • PUBLIC : インターネットに公開。接続元制限は不可。
  • VPC_ENDPOINT : 従来のVPC Endpoint構成。 ※いまは以下の VPC 構成が推奨されている
  • VPC (Internet Facing) : インターネットに公開。接続元制限可能。
  • VPC (Internal) : VPC内部向けに公開。接続元制限可能。

VPC_ENDPOINT構成は事実上の非推奨なのでこれから新規にTransfer for SFTP環境を作る際は考えなくて大丈夫です。
SFTPサーバーを

  • インターネットに公開する必要があるか?
  • 接続元を制限する必要があるか?

の2点で考慮し、

  • インターネットに公開する、接続元は制限しない : PUBLIC
  • インターネットに公開する、接続元は制限したい : VPC (Internet Facing)
  • インターネットに公開しない : VPC (Internal)

を選ぶと良いでしょう。

AWS Transfer for SFTPの構成図

ここからは各構成の図例を紹介します。
ここまでの説明を図にしただけですが、図がある方がより理解も進むと思いますので。

PUBLIC : Public Endpointの構成図

最初にPublic Endpoint構成の場合の図を紹介します。

この場合はVPCは基本関係せず、リージョン毎のエンドポイント(sftp://s-xxxxxxxx.server.transfer.[region-name].amazonaws.com)が公開される形になります。
エンドポイントに対してRoute 53などのDNSでCNAMEを設けることも可能です。

VPC_ENDPOINT : VPC Endpoint構成

前節で事実上の非推奨と説明しましたが一応紹介しておきます。
VPC Endpoint構成では、手動 で事前作成したVPC Endpointを経由してTransfer for SFTPにアクセスする方式になります。
ユーザーからみたアクセス先はVPC EndpointのENIになります。

この構成でインターネットに公開したい場合は以下の様にNetwork Load Balancer(NLB)を使います。

VPC Endpointにセキュリテグループはありますが、外部に公開しているのがNLBですのでセキュリテグループは使えずNACLを併用する必要があります。

VPC : VPC (Internet Facing)構成

インターネットに公開するVPC構成の図です。

この場合は事前にEIPを用意しておき、Public Subnetに自動生成されるVPC EndpointとEIPを紐づける形でエンドポイントを公開します。
Public Endpoint構成同様、エンドポイントに対してRoute 53などのDNSでCNAMEを設けることが可能です。

EIPとVPC EndpointのENIが紐づく形となっているのでVPC Endpointのセキュリテグループで接続元を制限することが可能です。

VPC : VPC (Internal)構成

VPC内部公開向けのVPC構成の図です。
VPC Endpoint構成とほとんど同じですがVPC Endpointが自動生成される点が異なります。

この場合はVPC Endpoint構成同様にアクセス先はVPC EndpointのENIになります。

また、未検証ですがVPNやDirect Connectをはさんでオンプレ環境からもアクセス可能なはずです。
(本記事では別VPCをオンプレ環境に見立て、VPC Peering経由で別VPCから接続できるところまでは確認しました)

加えて、VPC Endpoint構成では前段にNLBをおくことで冗長構成に対応していたことから、VPC (Internal)構成においても以下の様にNLBをおくことで冗長構成にできると思われます。

(「サポートしている」と明言したドキュメントを見つけることができませんでした...)

ここについてはNLBでなくDNSを使った負荷分散でも良い気はします。

最後に

以上となります。

本記事で紹介した様にTransfer for SFTPの構成は歴史的経緯により結構変わっており初見では分かりにくいところがありました。
私自身もよくわからなかったため自分自身の整理のためにこの記事を書いてみました。

これからTransfer for SFTPの導入を検討している方の役に立てば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.